Application developers invest a lot of time in releasing a software product. However, trade-offs in the design cycle and unforeseen or undiscovered issues may cause a developer to release an update (e.g., a patch) to a software product. Unfortunately, a software update that the developer releases to resolve an issue may itself inadvertently cause a problem in the software product. Thus, the developer may ultimately desire to recall the software update to remove the update from a machine where it is applied. In the example of a corporate environment, the deployment of a software update may result in conflicts between different lines of business applications. Until a user addresses such conflicts, he or she may desire to uninstall the software update from corporate machines so that the business applications remain functional.
Presently, to uninstall a software update, a user (e.g., an administrator) would typically uninstall the software product completely. The user then reinstalls the software product and reapplies software updates excluding the update that caused an issue in the product. However, given the volume of updates that a developer may release for a software product, it may be difficult for the user to undergo this tedious process. For example, if a software product installed on a machine includes 19 applied patches, and the 20th patch causes the product to function improperly, a user would have to uninstall the software product, reinstall the original version of the software product, and then reapply the 19 patches to the software product. This process may cause the user to incur significant costs and time to uninstall a single patch.
Another existing approach to uninstall a patch is for an update author to create a corresponding undo patch that has the reverse effect of the patch being installed. However, since this patch merely reverses the changes made by the original patch, changes to the same resources by other patches applied to the software product are ignored. Accordingly, applying the undo patch often results in an incorrect or undesirable product state.
In another existing approach, an installation engine stores the original state of the resources modified by the patch when the patch is being installed. When uninstalling the patch, the installation engine merely restores these resources back to the previously stored state. Since this simply restores the resources to a state before the original application of the patch being uninstalled, other updates to those resources by subsequent patches are ignored. Accordingly, uninstalling a patch in this manner may also result in an incorrect or undesirable product state.
Accordingly, a solution that effectively uninstalls a patch applied to a software product without unduly compromising the desired product state is desired.